Daniel 是公司的產品部經理，在兩三年前他們有一個當年度非常重要的產品，總共花費的時間大概有半年。在經過半年的努力（當然包含無數個加班的夜晚）之後，終於把這個產品全部都做完並且測完了。
老闆非常的期待，就來參日他們的 Demo。Demo 完了之後老闆對於成果蠻滿意的，感覺整體品質也不錯，但也提出一些疑慮。他說：「咦，原本我記得這個產品有一些附加功能，是後來加上去的，為什麼 Demoe 沒看到？」
Daniel 解釋道：「這個附加功能因為是後來才中途加入的，於是我們打算先把這一個案子完成，後續再馬上安排時間把這個附加功能加上去。」
老闆表示理解，畢竟他也知道中途加東西進去，沒有辦法馬上全部都完成是很合理的，於是他就問 Daniel：「那你們今天 Demo 這一個版本什麼時候要上線？」
Daniel 自信滿滿地說：「我們先 Hold 在這裡，等附加功能做完再上線。」
如果各位跟筆者差不多年紀，就應該玩過（或至少聽過）一款網多人連線遊戲叫做「世紀帝國」，就算沒有聽過世紀帝國，也應該聽過另外一款更紅的，由暴雪遊戲公司出的「星海爭霸」吧。
這兩款遊戲在上線之後都獲得很多玩家的喜愛，而他們有一個共同點，就是在推出後的幾個月，都各自又再推出了一到數款不等的「補充包」。
筆者當時年紀小，以為這些東西是遊戲公司推出之後，發現玩家喜歡，於是就趕緊加碼追加開發的新功能，後來長大一點覺得不對，這應該是遊戲公司為了多賺一點錢，而後來另外再加上去的附加功能。
這幾年再回頭一想，當時都錯了，原來這些補充包啊，是遊戲公司本來就要做的事情，只是為了搶佔市場先機以及快速獲得回饋，而延後推出的附加遊樂功能。目的就是當然第一個是搶佔市場先機，除此之外更是為了能取得真正的玩家回饋之後，趕快回頭調整正在開發中的補充包內容，以確保這個附加功能可以迎合真正玩家的口味。
「用戶要什麼就給他什麼」，這大家都知道，但是用戶真的知道自己要什麼嗎？其實，大部分從用戶口中說出來的需求，都不是他真正想要的東西。
你看最近 20 年來台灣的新聞最紅的那些內容，對照觀眾每天在網路上抱怨新聞的內容過於低俗的文章，兩相對比，就能窺知一二。
在現代這個線上服務發達的年代，你要每天都更新功能是非常簡單的事情，無論如何，也絕對比 25 年前世紀帝國流行的時候還要簡單得多了。你大可以每天新增一些新的功能，而這些新的功能很可能是上個禮拜或者前兩三天獲取的數據，分析之後得到的結果。
甚至，你可以用很普遍的另一種操作方法，當我不知道兩種功能哪一個好，我就偷偷把用戶分群，看看這兩種功能在不同群的用戶身上表現怎麼樣再決定我要把哪一個功能摒棄掉、哪一個功能扶正變成正式功能。
這些事情在現代的網路世界中，在你不知道的地方，每天每天地默默發生著。其目的說到底，也就是為了減少浪費、創造價值，如此而已
回到 Daniel 的 Case，他們今天有也許有20個功能聚集在一起，變成一個完整產品，而其中五個是延伸附加的功能，是後來才做到一半才加上去的。這時 Daniel 的做法是：第一次提出的15個功能先做完，然後再追加後續五個功能。
這個有兩個問題：首先後來提出的功能就一定比前面提出的功能還要不重要嗎？非常難講，很有可能後面提出的五個功能有其中四個是你必須要在 MV P 裡面展現的，他才能提高那個 MVP（Minimum Valuable Product）的價值。
其次，就算你把這些東西都安排好了，你從20個功能中精心挑選了 15 個要在MVP 裡面，那你的 MVP 上線了嗎？很明顯的Daniel沒有上線。那沒有上線的東西你就不能說他是 MVP 的對吧？你不能說你把功能做完了對吧？沒有上線的東西做完又有何用呢？因為他沒有辦法幫助公司創造一個價值。
因此，像 Daniel 這樣子的拆分與交付方式，我認為他當初並不是站一個非常為公司利益考量的思維邏輯中，所做出的決定。此時，團隊在這半年中所付出的努力，也沒有辦法在工作全部都做完之後，獲得一定程度的獎勵。這裡所謂的獎勵，也就是產品上線服務後創造價值的成就感（或現實一點，績效或獎金）。
這樣子的決策對於團隊士氣來說也是一大損害，就更別提公司的利益了。
什麼才是 MVP，圖片取自：https://www.yatilabs.com/blog/minimum-viable-product/
所謂的 MVP 就是最小可行性商品，重點在「可行」。這個東西要怎麼樣判定他可行，也就是可獲利、或至少可確認是否獲利，對吧？當你今天把整個產品切成 MVP、延伸一、延伸二… 依此類推的時候，你的 MVP 要怎麼讓他「V」呢？除了上線之外沒有別的辦法。應該說：
上線雖然非充分條件，但至少絕對是必要條件。
因此，對於一個長期經營的產品來說，慎選拆分的維度與粒度，是非常重要的事情。你一定要確保每一次工作結束之後產生的功能，必須要有附加價值，所謂的附加價值就必須要真的能夠產生價值，也就是至少至少一定要上線，而且能以用戶看不出來你還沒做完的樣子呈現。
這時可能有人會 Argue 說，可是我的附加功能還沒有完全完成，我擔心上線了之後有些有些有用戶會對產品產生壞的印象。這的確是會的，如果你有這種擔心的話，你有至少兩種可變通的做法：
變通做法一，你可不可以透過用戶的分析，挑選出一定 %數的用戶，譬如說 5%，讓他們去試驗這一個新的產品？在這樣子的實驗模式底下，用戶是真的，產品是真的，功能也是真的，所有東西都是真的，只有 %數降低而已。這樣子的實驗做出來的結果可信度是很高的，你就不需要擔心其他 95% 用戶會產生產品體驗不好的印象，因為他還不知道這些產品，對吧？
變通做法二，你可不可以把這個 MVP 偷偷包裝成一個假的新產品？也就是，你那 20 個功能全部都做完的完整產品是你主打要推推出的，但是你在前15個關鍵功能已經做完之後，就先推出一個看起來像是不同的產品。如此一來，產品是真的（只是包裝成另外的樣子），玩家是真的（只是他不知道他正在參與實驗）數據也是真的（因為玩家的體驗就明白的在那個地方」。你不但可以獲得一定的利潤還，可以收集真實的數據，為你手上正在進行的延伸功能提供真實的回饋與改善的依據。
依照你所在的產品、環境、產業、技術能力的不同，你有無限多種可能的變通做法。
辦法是人想，的需求來的順序不一定代表重要程度的順序。我們都知道時間有限的情況下把大功能拆小，並且安排順序後分次實踐是敏捷開發當中很重要的一個工作模式。把大功拆小的方向、維度，與粒度，是產品負責人應該要謹慎拿捏的事情。這件事情大部份時候沒有什麼標準可言，但如果真要講的話，唯一就是你的 MVP 是否真的能夠創造價值，後面就是你要怎麼在 User 受到的影響最小的情況下，把依真實數據調整後的延伸功能附加上去，或者是release 上去，讓用戶能夠享受到，這個就是拆分與安排順序的技術了。
謎之聲：「或者是藝術。」
iThome鐵人賽
看影片追技術